-
Notifications
You must be signed in to change notification settings - Fork 3.9k
census: expose client interceptors #12050
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm approving, but do consider the other API I mention in a comment, and whether we want to do that instead.
/** | ||
* Returns a {@link ClientInterceptor} with default tracing implementation. | ||
*/ | ||
public static ClientInterceptor newClientTracingInterceptor() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seeing all the statics is making me see why to more closely mirror GrpcOpenTelemetry. This could be fine as-is, because we don't care about it too much, but there do seem to be advantages in the GrpcOpenTelemetry API in clarity and letting us add options when needed.
If we had only configureServerBuilder()
and configureChannelBuilder()
on GrpcCensus
and a builder to enable/disable stats/tracing, then gRPC could continue choosing the interceptor/tracer order and it would make configuring both OpenTelementry and OpenCensus more obvious.
No description provided.